Generally speaking, mobile radio systems are covered by standards and more information can be obtained from the corresponding standards published by the corresponding standards organizations.
FIG. 1 outlines the general architecture of mobile radio systems, essentially including:                a radio access network (RAN) 1, and        a core network (CN) 4.        
The RAN is made up of base stations 2 and base station controllers 3 and communicates with mobile terminals 5 via a radio interface 6 and with the CN 4 via an interface 7. Within the RAN, the base stations communicate with the base station controllers via an interface 8.
In the UMTS, the RAN is called the UMTS terrestrial radio access network (UTRAN), a base station is called a Node B, the base station controllers are called radio network controllers (RNC), and a mobile terminal is called a user equipment (UE). The radio interface 6 is called the Uu interface, the interface 7 is called the Iu interface, the interface 8 is called the Iub interface, and an interface 9, called the Iur interface, can also be provided between RNCs.
The RNC controlling a given Node B is called the controlling radio network controller (CRNC). The CRNC has a load control and radio resource allocation role in respect of each Node B that it controls. For a given call relating to a given UE, there is an RNC called the serving radio network controller (SRNC) having a control role for the call concerned. In the case of macro-diversity transmission (also called soft handover), a Node B connected to the UE but not controlled by the SRNC communicates with the SRNC via the RNC controlling it, called the drift RNC (DRNC), via the Iur interface.
In the UMTS in particular there is an integrity protection function for protecting the integrity of specific information sent via the radio interface, namely signaling information exchanged in the context of mobility management, call management, session management, etc. protocols. This information is transmitted via the radio interface in messages called radio resource control (RRC) messages defined in the SRNC/UE signaling protocol, which is called the RRC protocol.
For a description of the RRC protocol and the integrity protection function, see in particular specifications 3G TS 25.331 and 3G TS 33.102 published by the 3rd Generation Partnership Project (3GPP). There follows a brief summary of the mechanisms used to protect the integrity of messages exchanged between a sender (a UE in the uplink direction or an SRNC in the downlink direction) and a receiver (an SRNC in the uplink direction or a UE in the downlink direction):                for each message to be sent, the sender calculates a message authentication code (MAC-I code) using an integrity protection algorithm called the UMTS integrity algorithm (UIA) and input parameters of that algorithm, after which the sender inserts the MAC-I code calculated in this way into the message to be sent,        for each message received, the receiver recalculates the MAC-I code using the same algorithm and the same input parameters as the sender, after which the receiver compares the code recalculated in this way with the code received; if the two codes match, the receiver considers that the message received is intact and was sent by that particular sender.        
The algorithm input parameters include a secret parameter and public parameters. The secret parameter is called the integrity key (IK). The public parameters include:                a pseudo-random value (corresponding to a parameter FRESH),        a sequence number (corresponding to a parameter COUNT-I),        the message to be sent (corresponding to a parameter MESSAGE), and        the identity of the radio bearer (RB) on which the message is sent (corresponding to a parameter RB Id).        
The sequence number COUNT-I includes an RRC sequence number (RRC SN) and an RRC hyperframe number (RRC HFN).
Standardized message formats are used at open interfaces such as the Uu interface for RRC messages in particular. Accordingly, a sequence of bits to be sent is obtained from various information elements (IE) to be sent in a message, in accordance with coding rules conforming to an abstract syntax, for example the Abstract Syntax Notation 1 (ASN.1) syntax, which is used to define a data structure for the information to be sent, and a transfer syntax, such that data received in the form of a stream of octets or bits is correctly recognized on reception. For more details of this coding, for example for sending RRC messages at the Uu interface, see in particular the specification 3G TS 25.331.
As shown in FIG. 2, the RRC message bit sequence corresponding to an RRC message sent at the Uu interface includes:                a bit OP indicating whether the integrity of the message is protected,        if the integrity of the message is protected, an integrity check info bit sequence corresponding to an IE called the integrity check info,        choice bits enabling the receiver to determine which of the various RRC messages to be sent is sent in this instance,        a sequence of payload bits (denoted “message”) corresponding to payload information elements IE, and        where applicable, RRC padding bits to make the total length of the sequence sent a multiple of eight bits.        
The integrity check info IE contains:                a message authentication code IE which corresponds to the MAC-I code calculated on sending, and        an RRC message sequence number IE which corresponds to the RRC SN used on sending the message in question.        
The RRC SN is incremented for each protected message sent and the RRC message sequence number IE is used in the receiver, in particular to update the RRC HFN on each new RRC SN cycle.
Procedures are provided whereby the network communicates to the UE parameters for calculating the MAC-I code (including in particular the algorithm type and the pseudo-random value FRESH).
During a call, the SRNC role for the call can be transferred from a source SRNC to a target SRNC for various reasons, for example: optimizing the transfer time, optimizing resource allocation, optimizing the relative loads of the various RNCs, etc. This kind of transfer is effected in accordance with a relocation procedure.
There are two types of relocation:                relocation in which the UE is not involved, typically corresponding to a situation in which the target SRNC previously had a DRNC role, and        relocation in which the UE is involved, typically corresponding to a situation in which the target SRNC did not previously have a DRNC role.        
In the event of a relocation in which the UE is involved, procedures are provided whereby the network communicates to the UE, when it is still under the control of the source SRNC, various parameters to be used when it is under the control of the target SRNC, such as parameters relating to new radio resources to be used, and if necessary new parameters for calculating the MAC-I code (for example a new pseudo-random value FRESH and possibly a new algorithm type).
FIG. 3 shows procedures of the above kind from the current version of the standard.
A step 10 indicates that a relocation procedure has begun. The relocation procedure includes exchanges of signaling between the source SRNC, the target SRNC, the CN and the UE, as defined in particular in the specifications 3G TS 25.413 and 3G TS 25.331 published by the 3GPP. The specification 3G TS 25.413 relates to the Radio Access Network Application Part (RANAP) signaling protocol that applies at the Iu interface. As previously indicated, the specification 3G TS 25.331 relates to the Radio Resource Control (RRC) signaling protocol that applies at the Uu interface.
In a step 20 the target SRNC creates information called RRC information. The corresponding information unit created by the target SRNC is called the RRC information, target RNC to source RNC information unit; it is referred to more simply hereinafter as the RRC information unit. An RRC information unit is intended to be sent in messages other than messages at the Uu interface, for example messages at the Iu interface, or RANAP messages, for example the RELOCATION REQUEST ACKNOWLEDGE and RELOCATION COMMAND messages. These RANAP messages contain an IE corresponding to an information container called the target RNC to source RNC transparent container, which itself contains an IE corresponding to an information container called the RRC container, which in turn contains the RRC information, target RNC to source RNC information unit. RRC information created by the target SRNC is thus transferred to the source SRNC, which forwards it to the UE in an RRC message at the Uu interface. The RRC message can be one of the following messages, for example: RADIO BEARER SETUP, RADIO BEARER RECONFIGURATION, RADIO BEARER RELEASE, TRANSPORT CHANNEL RECONFIGURATION, PHYSICAL CHANNEL RECONFIGURATION.
The RRC information unit created by the target SRNC includes an integrity protection mode info IE which can in turn include MAC-I code calculation parameters (such as the algorithm type and the pseudo-random value FRESH).
Coding based on the ASN.1 syntax is also used and as a result of this coding (see FIG. 2):                an RRC information, target RNC to source RNC bit sequence, corresponding to a RRC information, target RNC to source RNC information unit, contains:                    choice bits enabling the receiver to determine which of the corresponding eligible RRC messages is sent in this instance,            a message bit sequence corresponding to payload information elements,                        an RRC container bit sequence contains:                    a bit sequence corresponding to the RRC information, target RNC to source RNC sequence,            where applicable container padding bits, so that the number of bits in the RRC container sequence (defined, in accordance with the coding rules used, as an OCTET STRING) is a multiple of eight bits.                        
In a step 30 the target SRNC sends the CN a RELOCATION REQUEST ACKNOWLEDGE message, which includes a target RNC to source RNC transparent container IE in turn containing an RRC container. The RRC container in turn includes an RRC information unit created in step 20.
In a step 40 the CN sends the source SRNC a RELOCATION COMMAND message which contains the target RNC to source RNC transparent container IE received by the CN of the target SRNC.
Thus in steps 30 and 40 the RRC information unit created in step 20 is transferred transparently from the target SRNC to the source SRNC via the core network.
In a step 50 the source SRNC decodes the RRC information unit received, in particular to verify if new MAC-I code calculation parameters have been sent. On the basis of the MAC-I code calculation parameters, the source SRNC calculates the MAC-I code to be inserted into the message to protect its integrity when sending it to the UE at the Uu interface.
As shown in FIG. 2, with the current version of the standard the message sequence of the coded RRC information unit corresponds to the message sequence of a coded RRC message and consequently the source SRNC must calculate the MAC-I code in order to construct the integrity check info sequence of the coded RRC message. In step 50, after the MAC-I code has been calculated in this way, the source SRNC constructs the sequence of bits corresponding to the coded RRC message to be sent to the UE at the Uu interface (see FIG. 2).
In a step 60 the source SRNC sends the RRC message obtained in this way to the UE.
The applicant has noted that a method of the above kind has the following drawbacks, for example:                it is necessary for the source SRNC to decode the RRC information unit to verify the MAC-I code calculation parameters and then to calculate the MAC-I code on the basis of those parameters, which has the drawback that this increases the quantity and complexity of processing in the source SRNC,        it is necessary for the source SRNC to be able to implement the type of algorithm chosen by the target SRNC, or the target SRNC cannot choose a type of algorithm other than that implemented in the source SRNC; in other words, this has the drawback of either relatively severe constraints or a lack of flexibility, and        to transfer RRC information in RANAP messages, it is necessary for the target SRNC to use a format known to the source SRNC, or the target SRNC cannot choose a format other than that known to the source SRNC; in other words, this has the further drawback of either relatively severe constraints or a lack of flexibility (for example in the situation in which a new protocol version has been specified and one of the two SRNCs is using the new version and the other one is using the old version).        
In other words, with the current version of the standard, a number of conditions must be satisfied between the source SRNC and the target SRNC:                the source SRNC must be able to decode all messages that the target SRNC may send via the CN,        the source SRNC must know all the optional extensions that the target SRNC may include in the message,        the source SRNC must support a message version that the target SRNC is using, and        the source SRNC must support the integrity protection mechanism that the target SRNC has chosen.        